home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1761 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.9 KB
  1. Path: news.mcs.net!not-for-mail
  2. From: maney@MCS.COM (Martin J. Maney)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Name-mangling standard
  5. Date: 12 Jan 1996 13:09:21 -0600
  6. Organization: MCSNet Services
  7. Message-ID: <4d6bl1$1gh@Venus.mcs.com>
  8. References: <20c.32169.607@newage.com.ar> <4bsnbu$5mu@mujibur.inmind.com> <30EDC013.7C780E5E@cims.nyu.edu> <DL1pqE.KKq@infosoft.com>
  9. NNTP-Posting-Host: venus.mcs.com
  10. X-Newsreader: TIN [version 1.2 PL2 (KSD)]
  11.  
  12. [I'm honoring the Followup-To John set, but that means that I won't see 
  13. replies to this.  If anyone wants to discuss this with me I'm afraid 
  14. you'll have to use e-mail.  maney@mcs.com]
  15.  
  16. John Galt (jgalt@infosoft.com) wrote:
  17. [John didn't write this next bit]:
  18. > > I certainly hope not!  Name mangling is a solution to passing type
  19. > > information to 1950's linkers.  Once linkers become more sophisticated,
  20. > > name mangling can disappear back into the slime from which it came.
  21.  
  22. Observe the phrase "linkers become more sophisticated".  This is an old 
  23. idea that we may hope will someday come to pass, that linkers might learn 
  24. that there is more to a function than a single text label.  And so...
  25.  
  26. > I beg to differ.  Name mangling serves several indispensible functions:
  27.  
  28. > 1.  It makes it possible to have more than one function with the same name
  29. > (differing in their argument lists).  To do this without mangling, the linker
  30. > would have to see not just a function name, or even class::name, but a full
  31. > _prototype_ for each function (omitting variable names and the result type).
  32.  
  33. Yep, that's exactly what a more sophisticated linker might do.  It might 
  34. do even more; it would, in any case, make this information available for 
  35. all other tools in a consistent form.  There may be reasons to dislike 
  36. this, but your notion that it would break overloading simply misses the boat.
  37.  
  38. > 2.  It allows the linker to do error checking.  Example:  Module A calls
  39. > foo() in module B.  I change the definition of foo (and its argument list)
  40. > but forget to change A.  Without name mangling, the program will simply crash
  41. > (or do strange things because I've clobbered the stack...)
  42.  
  43. Ditto.  (comparing signatures is the same mechanism whether it's 
  44. resolving overloading or testing consistency.  two sides of the same coin.)
  45.  
  46. > On systems like the PC, with multiple pointer formats, this could also be
  47. > used to check that all modules (including library code) were compiled with
  48. > the same (or compatible) memory model.  I think it is really stupid that none
  49. > of the compilers for the PC makes this possible by including the memory model
  50. > in mangled names.
  51.  
  52. This would be an argument in favor of replacing name mangling with a 
  53. smarter linker, if anything: a smart linker for a multi-model machine 
  54. should certainly include such checking.  FWIW, the late, lamented Zortech 
  55. compiler - the real one, before Symantec bought the name - DID 
  56. incorporate near/far and other 80x86-specific stuff into its mangled 
  57. names.  Guess it's still ahead of the competition in some respects.  Not 
  58. bad for a product that's been "dead" for so many years!  :-)
  59.  
  60. > 3.  When linking with other languages such as Pascal, it in effect checks that
  61. > you told the C++ compiler to use the calling sequence for the language that
  62. > the function you're calling is in.
  63.  
  64. Ditto re: smarter linkers.
  65.  
  66. > In short, wanting to eliminate name mangling is like wanting a compiler that
  67. > never prints error messages.  It's for people who would rather walk off a
  68. > cliff than have someone tell them they're about to.
  69.  
  70. Since all I'm certain I've seen of the article to which you're replying 
  71. is the scrap you quoted, it's barely possible that the author HAD meant 
  72. something awful like this, but I doubt it.  The idea of teaching linkers 
  73. to deal with the signatures of functions more directly and thus obsoleting 
  74. the name mangling kluge isn't new.  Why, I believe Stroustrup made 
  75. passing mention of it all the way back in the first edition.
  76.  
  77.